About the PR

This PR refactors the entirety of Admin Help.

Why / Balance

Admin Help was an old old system not up to standards at all. This PR refactors admin help, bringing it to modern codebase standards. This PR is made as a draft PR to get feature requests in and to allow early reviews where possible so that I do not have to refactor a refactor.

You can track current progress on this PR here:
https://jetfish.iterator.systems/projects/0199d82e-3c62-7e94-b61e-2c81db27118e

Use this link to view all current capabilities of the system and planned features.

Technical details

The bulk of the refactor is to atomize admin help. Admin Help is now based on prototypes.

- type: bwoinkChannel
  id: AdminHelp
  name: bwoink-channel-ahelp
  helpText: bwoink-channel-ahelp-help
  order: -1 # We always want this one to be the first
  features:
  - !type:SoundOnMessage
    sound: !type:SoundPathSpecifier
      path: /Audio/Effects/adminhelp.ogg
  - !type:RequiredFlags
    flags: Adminhelp

This allows modular adding of features to admin help without hardcoding many of the values.

The core pillar is that admin help is now split into "channels". These channels are shown via a selector in the F1 menu. The intent is that adding something like a "discord relay" is as simple as adding that to the feature of the channel and from there a separate manager goes and handles it.

For how this entire code is now structured:
BwoinkSystem is now BwoinkManager.
SharedBwoinkManager handles the shared utility methods. ServerBwoinkManager and ClientBwoinkManager handle the relevant implementations on their respective sides.

The server and client both hold a Conversations Dictionary. It is synced to the client, allowing for admins to see the full history of a player. Systems and other managers can easily hook into the admin help system via MessageReceived.
A message object holds the properties as you would expect: Sender, Time, Content and importantly the message flags.
The old system had messages use a complicated case of "just add more properties to the message object". While this works I opted for the more extendable system of adding an Enum to the message object "MessageFlags":

[Flags]
public enum MessageFlags : byte
{
    None = 0,

    /// <summary>
    /// The person who sent this message is a manager for this channel.
    /// </summary>
    Manager = 1,

    /// <summary>
    /// This message should not result in a sound.
    /// </summary>
    Silent = 2,

    /// <summary>
    /// This message can only be seen by other managers of this channel.
    /// </summary>
    ManagerOnly = 4,
}

I request that any feature requests and/or concerns regarding design be raised now so that I can fix them.

In its current form, the system works for basic ahelps, but I am still re-implementing the systems of the old ahelp.

Media

https://memory-conflux.iterator.systems/bwoink%20refactor_1.mp4
TODO.

Requirements

• I have read and am following the Pull Request and Changelog Guidelines.
• I have added media to this PR or it does not require an ingame showcase.

Breaking changes

TODO
BwoinkSystem.cs was removed on the client and server. Use BwoinkManager.cs

Changelog